home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄26⁄90 / 0512-Re Seeking Volunteer-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.9 KB  |  45 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  BURBECK.S    to ALCABES
  2.  
  3. Item    0480774                         23-Jan-90        13:33
  4.  
  5. From:   BURBECK.S                       Burbeck, Steve
  6.  
  7. To:     SOFTARCH                        SW Architects, Carl Nelson,PRT
  8.  
  9. cc:     JESSA                           Vartanian, Jessa
  10.         MACAPP.ADMIN                    Design Methodology,Joel Norvell,VCA
  11.         MA.ARCHIVES                     MacApp Archive Administration
  12.  
  13. Sub:    Re: Seeking Volunteer for A M
  14.  
  15. Carl,
  16.  
  17. I take your link as one -- well, for you, two -- votes for Jeffs idea.  Of the
  18. ideas that have surfaced so far, I consider the following to have particular
  19. merit:
  20.  
  21. 1) Jeff's  MacApp.Daily$ and MacApp.Weekly$:  This allows people to have daily
  22. or weekly access to the MacApp discussion on a controllable basis (i.e., they
  23. know what they're in for when they doubleclick the item in their inbox window).
  24. The disadvantage is that it requires an especially dedicated volunteer to
  25. collect, compress, and post the daily traffic.
  26.  
  27. 2) The notion that people could have two Applelink addresses, one public for
  28. normal traffic, and one reserved for inclusion in MacApp.xxxx$ and/or other
  29. group addresses that generate awkward ammounts of traffic.  This too is
  30. controllable.  And if Applelink administration is willing to allow such a thing
  31. (at little or no extra cost) it has the advantage of avoiding the requirement
  32. for a dedicated volunteer to administrate the links.  But I have no idea what
  33. impact it may have on Applelink administration.  Jessa, any ideas there?
  34.  
  35. 3) Absorbing good bbs behavior into the Applelink Mainframe.  This is the ideal
  36. solution, but is unlikely to be done for at least a year, perhaps two.
  37.  
  38. If we can find a volunteer to do reliable daily maintenance, I like the first
  39. idea.  Otherwise, I hope we can do something along the lines of the second
  40. idea.  If neither works, I think we should simply stick with the present
  41. scheme.
  42.  
  43. Steve Burbeck
  44.  
  45.